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ABSTRACT 


This paper reports on the design of a computer simulation model 
written in GPSS. A brief description of the System/360 operating 
system is given. The model consists of macroscopic modules repre- 
senting distinguishable computer tasks which are capable of indepen- 
dent operation and/or more detailed expansion. A pseudo jobstream 
of sufficient detail was used to test the viability of this model. 
Guidelines for experimentation (which was prohibited by a complete 


lack of data) are outlined; suggested uses of the model are given. 
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CHAPTER I 


I, INTRODUCTION 


A well designed simulation model can effectively predict system 
performance under a variety of conditions for a relatively low cost. 
This efficiency becomes an even more important tool when the system is 
an expensive computer where even subtle changes are costly in time and 
money. Such a model has been constructed for the IBM 360/67-2 recently 
acquired by the U.S. Naval Postgraduate School: it is basically macro- 
scopic in design, although facilities have been provided throughout 
for refinement of statistics at the microscopic level. It depicts 
operation utilizing the IBM Operating System/360 in an MVT environment. 
The model developed allows one to analyze an existing system or test 


proposed configurations. 


A. BACKGROUND 

Since the arrival at the school of the System/360, the system 
implementation and operation has been based on the recommendations pro- 
vided by IBM engineers and literature, and those of the school's staff 
of system programmers. Although the operation has continually improved 
over the past eighteen months, it has been at no small expense to the 
users; system configuration and development experiments have been per- 
formed with the normal jobstream. 

The users consist of students, staff and faculty in varying per- 
centages, dependent on the time of year. Student usage consists of 
beginning FORTRAN programmers, Computer Science students engaged in 


advanced and systems programming, and thesis students. The staff work 


is devoted to maintenance of academic records and schedules, and such 
operations as the student text and classified document libraries. 
Faculty utilization is by computer class instructors and those engaged 
in research projects. The computer staff's applications and systems 
programmers are, of course, utilizing the facility. With few excep- 
tions, all users are in equal competition for the use of the computer, 
and at no expense to the individual except for his time. It is not 
unusual to find the backlog of jobs waiting to be processed in excess 
of twenty-four hours at the peak period of the quarter. 

Although work is now in progress on a comprehensive accounting 
system, timing data on the jobstream is not presently available. The 
information needed to properly design the priority scheduling algorithm, 
necessary for efficient machine utilization, is also unavailable. 

Except for WATFOR batch runs and a few other jobs handled on an 
individual basis, the jobs are run on a first-in-first-out basis. This 
results in lengthy turnaround, much operator time spent in the mounting 
and dismounting of special disk packs, and an occasional system lockup 
when a job with unusually large requirements unexpectedly enters what 
might already be an overtasked system environment. 

The possibility of the addition of equipment (core and direct 
access facilities) to improve overall performance and the reconfigura- 


tion or elimination of present machinery is ever present. 


B. DEFINITION OF THE PROBLEM 

This paper discusses the design of a simulation model of the 360's 
Operating System in an MVT environment on a model 67-2 machine. When 
jobstream statistics are provided, the simulation model is designed to 


predict system performance with a degree of accuracy necessary for 


planning and evaluation purposes. By the manipulation of certain para- 
meters and/or blocks, the model may be made to conform to a variety of 
configurations and scheduling schemes. 

No data concerning the actual jobstream has been collected at the 
school as of this time, except for a manual count of the number of 
jobs run on a given day. This lack of information prohibits the use 
of comparative experimentation to validate the model other than at the 
most fundamental level. Comments concerning this phase of model 
development will therefore be restricted to a discussion of the tech- 
niques which should be used in experimentation when job data becomes 
available. 

Validation of this model was conducted by applying a pseudo job- 
stream, which is described in detail in Chapter III, to the model and 
conducting a parametric analysis of the important aspects of ail 
modules. In addition, these results were compared with the author's 
observations of the actual processing of similar jobs on the 360. 

The conclusions drawn will necessarily be concerned only with the 


viability of the developed model. 


CHAPTER II 


SYSTEM DESIGN 


The System/360 consists of numerous hardware devices and an 
operating system. A thorough knowledge of both these areas was a 
prerequisite to the development of this simulation model. This 
information is available from numerous I.B.M. publications; those 
referenced are thought to be representative and give a broad enough 
background for an understanding of the model. 

The configuration discussed here consists primarily of 2 central 
processing units (CPU's), 512K bytes of main storage, 1 drum and 8 
disk storage devices, 4 tape units, 2 card readers, 2 printers, a 
card punch, 12 communication terminals, a graphical display unit, 2 
graphical plotters, and associated channel control units. These are 
all interconnected through a switching device which allows many con- 
figurations including separate, simultaneous processing by the 2 
CPU's (9). Although the hardware can be utilized to support multi- 
processing, the MVT Operating System does not provide these capa- 
bilities; hence, only mono-processing is considered in the model. 
Five methods are provided for interruption of the CPU (program, 
supervisor call, external, I/0, and machine check). (8) 

The operating system is responsible for satisfying valid user 
request through proper job, task, and data management (5). The flow 
of system responcses and user requests is shown in Appendix A. Job 
management in MVT handles scheduling on a priority basis, interprets 


the user requirements, assigns devices, and initiates and terminates 


LO 


each job step. Task management includes resource allocation, and 
task supervision. Data management concerns itself with label pro- 
cessing, retrieval of data sets, buffer management and scheduling, 
and data set access (7). 

An MVT environment is one which allows several tasks to be 
simultaneously in core storage. Input readers, output writers, 
several user jobs, resident routines, and operator communications 
routines can all be in core at the same time, subject only to storage 
limitations. The various tasks compete on a priority basis for the 
CPU; interrupt handling procedures include switching to the highest 
ready task when appropriate. Thus simultaneous job processing and 
I/O operations are possible with this multitasking situation (10,11). 

A job presented to the computer is thus read into the queue of 
jobs awaiting processing by a reader/interpreter task, executed by 
an initiator/terminator task, and has its output processed by one or 
more writer tasks. The possible advantages of multitasking in terms 
of efficient equipment utilization are apparent; however, the analy- 
sis of such a system seems only tractable by means of simulation 
techniques. Available analytical techniques (14) require simplify- 
ing assumptions unrealistic for modeling a complex system such as 


MVT. 


lek 


CHAPTER III 


I. MODEL DESIGN 


A. GENERAL 

It is possible to model every individual operation of a computer 
system including hardware, control program, and jobstream in an exact 
manner. Such a simulation, when applied to multiprogramming situa- 
tions will result in a cwmbersome model which requires as much or more 
running time as the actual operation. It is the objective of this 
study to provide a simple model whose behavior is representative of 
that of the real system. At the same time it is necessary to provide 
expansion points for future study and model refinement. Thus a com- 
plex operation may be represented by a simple delaying "advance" block 
(2);if it is necessary to examine that facility more closely, the 
single block could be replaced with a series of detail blocks which 
more accurately approximate the operation. 

The ease with which various sub-systems could be constructed from 
block diagrams and the provisions for handling interupts of trans- 
actions on a priority basis led to the choice of GPSS/360 for imple- 
mentation of the model. Certain simplifications of the model were 
necessary to accommodate language restrictions or those imposed by the 
demands of processing time. 

The model reflects the configuration of the IBM 360 model 67-2 
computer operated at the U.S. Naval Postgraduate School under release 
14 of the Operating System generated for option 4, Multiprogramming 


with a Variable number of tasks. It is expected that minor modifica- 


tions of the model will be required for its application to subsequent 
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versions of the MVT operating systems. 


B. JOBSTREAM GENERATOR 

The jobstream generator module was designed for the purpose of 
exercising the model only; it must be replaced in order to obtain use- 
ful experimental results. Each jobstep is represented by a transaction 
which is created by a generate block. The job and step attributes are 
represented by the values of parameters associated with each trans- 


action as indicated in Table l. 


The job's PRTY parameter initially, and sub- 
sequently its dispatching priority during 
execution 

Varies; used for communication between moduies 
Number of steps in the job 

Number of input records (cards) 

Number of Class A output records (print) 

Size of REGION required in K (1024 bytes) 
Execution time (CPU) in milli-seconds 

Mean CPU time between interrupts 


Number of Class B records (punch) 


Initiator being utilized during execution 





Table 1. Parameter Association for Jobstream Generator 


The present jobstream consists of identical one step jobs. The 
parameters were chosen to be representative of an average student job 
Which exercised all modules of the model. The selected parameters are 


shown in Table 2. 
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| Parameter | Value | Meaning 


Selection Priority 

Number of steps 

Number of input cards 

Number of Lines of print 
Region size 

Execution time in milli-seconds 


Milli-seconds between interrupts 





Number of output cards 


Table 2. Parameter Values for Pseudo Jobstream 


The priority of eight is the present default priority at the school. 
Execution time, region size, input cards, and output lines and cards 
are about average for a student job. The time between interrupts was 


an arbitrary number used to test the interrupt mechanism. 


C. READER/INTERPRETER 

The reader/interpreter module enters the jobstream into the system 
jobqueue and input spools.. Those jobs which are marked as having 
job control language errors are processed in a "jobfail'' mode. Default 
parameters are not provided by the reader for jobs as this was thought 
to be a simple external task and would degrade the operation of the 
module, Each job step transaction must therefore be presented to the 
reader with all required parameters supplied. 

The module will operate multiple input streams if desired, each of 
which needs 42K of core. The starting and stopping of readers is con- 


trolled by the contents of the jobqueue. Processing time for each job 
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is dependent upon the number of steps and the number of cards read. 

To operate the model the reading rate was assumed to be 1000 cards per 
minute, the maximum speed of the 2540 card reader. Since the reader/ 
interpreter does not always operate this rapidly, modification should 
be made when timing information is available. The formula used for the 
number of spooling tracks needed, (P3/401+1)10 is based on the 2311 
disk drive's track capacity and the present default of 10 tracks per 


extent. 


D. OUTPUT WRITER 

The system output writers handle all final output associated with 
each job and the purging of the job from the simulation. Multiple out- 
put devices are supported; each requires 28K of core. The class B 
(punched) output is allowed to back-up to a given level before it is 
punched; and then it operates until the queue is empty. The class A 
(printed) output writer operates for the entire simulation run unless 
it is redefined between start control cards. A start-stop system 
Similar to that devised for the punch could be applied to the printers 
if desired. Processing time required for the writer is dependent on 
the number of records produced by the job and the speed of the output 
device. The use of special characters which slow the processing time 
were not considered in this model. It is felt that this situation 
would best be handled by providing a separate class for this type of 
output. The output formulas P4/27+1 and P8/42+1 for class A and B 
outputs respectively are based on the track capacity of the disks. 


The print speed was set at 1200 lines per minute. 
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E. IPL 

The IPL module conducts the Initial Program Load by defining the 
systems configuration parameters for the simulation run. The IPL 
transaction enters core in the amount of the nucleus/system queue area 
plus the link pack/master scheduler area. It starts the appropriate 
number of readers, initiators, and writers, then moves to the start- 
stop loops where it operates for the remainder of the simulation. 
This module is provided to allow simulation of system restart, as well 
as a convenient and realistic method for specifications of system para- 


meters. 


F. INITIATOR/TERMINATOR 

The initiator/terminator provides the processing support for the 
jobstream. The job, once having entered the initiator, is processed 
by the ENQ routine. It was felt that the enqueing of resources was 
not of particular significance at this installation since the majority 
of users enqueue only on sharable resources, such as the system digee 
spools, and program libraries. The routine is branched to, however, 
in order to provide for expansion if necessary. The initiator then 
assumes the dispatching priority of the job and obtains core space 
(REGION) for it. The model does not ensure that this region is of 
contiguous core due to the characteristics of the 'storage' block in 
GPSS; this occasionally allows a job to be processed which would nor- 
mally be delayed due to core fragmentation (2). Proper operator tech- 
nique and job classification minimizes the possibility of core frag- 
mentation on the real system; hence, this discrepancy is not considered 
to unduly affect the model. 


Device allocation is handled by the allocate routine which assigns 
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devices to each job step which requires non-temporary data sets on 
direct access or tape storage. Experience thus far with the actual 
system opevaietionh has shown that temporary storage space is not a 
problem with the amount of spooling space provided, hence it is not 
considered here. If the number of spools should be reduced, this prob- 
lem might bear closer examination. Private disk pack allocation is 
handled along the lines of present day usage of such job libraries. 
Since the policy regarding the use of such disks may well change in 
the future, this portion of the model should be made to conform with 
the policy imposed. There are presently four spools and two private 
library drives in both the actual system and the model. 

The transaction is next released to process until completion. The 
CPU facility is preempted on a priority basis and a copy transaction 
is split off and acts as an interrupt for that step during processing. 
When the execution time parameter has been reduced to zero, the step 
is considered completed and the termination process is entered in order 
that devices may be freed and region released. If there are further 
steps, they now enter the initiation phase at the device allocation 
level and are similarly processed. If the previous job step was abnor- 
mally terminated, as indicated by an initial value of zero for the exe- 
cution parameter, the following steps are "flushed". The last job step 


is routed through the DEQ routine following termination, indicating 


The author was able to obtain several listings of the Volume 


Table of Contents (VTOC) on each of the spooling disk packs at 
different intervals including periods of peak spooling activity. 


At no time did these volumes exceed 50% of their combined capacity. 


i? 


job termination and releasing the initiator to select a new job. 


G. INTERRUPTS 

Only those interrupts which require task switching, i.e., those 
which place the current task in a wait state, are considered. This 
was done because other types of interrupts are already included in 
the job execution time. To include these would require more simu- 
lation time, complicate the model, and add little to the results. 
At random times during the processing (the distribution is deter- 
mined by the interrupt parameters of the job step) these interrupts 
preempt the CPU and place the current task in a wait state; this is 
followed by interrupt processing time and the initiation of parallel 
I/O processing. Upon completion of post-I/0 processing, the task is 
placed in a wait state and allowed to compete for the CPU facility. 
The buffer capability of GPSS which restarts the scan of transactions 
to dispatch that one which possesses the highest priority is used for 


task switching purposes, 


a Te 

Although facilities have been provided for channels, control units, 
and device units, little I/O operation is simulated due to the time 
consuming complexity of the operation. These operations are repre- 
sented rather well by simple advance blocks with times provided from 
standard distributions. If the area of I/O operation is found to be 
of interest and statistics from the actual system can be gathered, 
this module may be expanded to handle 1/0 with greater accuracy. The 
formulas in Table 3 are provided for computation of Channel and Control 


Unit facility given the unit facility number (F). 


18 










Channel O (F=21...84) 


Control Unit (F+111)/12 
Channel 1 (F=85) 9 

Control Unit Le/ 
Channel 2 (F=86...97) 10 

Control Unit (F-14)/4 


Table 3. Channel and Control Unit Calculation Formulas 


Individual unit assignments are listed in Appendix B. 

As an example the model card punch is facility 47 (F=47). Since 
F is less than 85 the actual Channel is O (model facility 8). The 
Control unit is the least integer in (47+111)/18=13. These formulas 


should be used for rapid calculation in I/O operations. 


&. PREORITY 

Transaction priorities are limited by GPSS to values between O and 
127, whereas those in the actual system range from 0 to 255; therefore 
the model uses numbers equal to one half of those used in the actual 


System (rounded down to the nearest integer), to represent priorities. 


i) 


CHAPTER IV 


I, RESOLUTION 


A. RESULTS 

As there was no data available concerning jobstream characteristics, 
measurements on hardware utilization, or processor utilization by 
system tasks (overhead), the validating results are from model opera- 
tions with the pseudo jobstream only. The runs were made with the 
parameters described in Chapter III and from one to three initiators. 
Statistics were gathered after three and six simulated hours. During 
the first hour, job generation only was done to provide an initial 
backlog. It was intended that the results be realistic and not 
necessarily accurate due to the complete lack of accurate input statis- 


tics. The results obtained are summarized in Table 4. 












3 Initiators 


































Jobs Generated 20 
Jobs Read 184 
Jobs Executed 162 
Jobs Printed 162 
Jobs Punched 147 
Average CPU Utilization 2a) 
Average Core Utilization 27 ON 






Average Spool Utilization 





Table 4. Sample Results from Pseudo Jobstream Runs 
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As expected, the amount of work accomplished was related to the 
number of initiators in operation. Resource utilization also increased 
as expected. The CPU utilization is much lower than actual since the 
system overhead has not yet been incorporated. Intermittent punch and 
reader operation based on queue sizes account for the differences in 
these figures and the increase in the number of jobs read. Other 
statistical output from these runs and a run of twenty-four hour dura- 
tion gave similar results. In each case this data supports the via- 
bility of the model. 

The actual running time of the model was a function of the number 
of transactions and the number of blocks in the system, with the former 
being by far the greatest factor. When transactions were changed from 
their representation as a job step to that of a complete job, the time 
was decreased by more than a factor of three. Exact figures for model 
timing are not available due to the absence of an accounting routine 
on the present system. The use of link chains, where possible, was 
also found to improve efficiency. The elimination of blocks which 
added little to the model due to their infrequent use or infinitesimal 
contribution to the delaying time of a transaction enabled a much 
larger sample of jobs to be completed in this same amount of computer 


time. 


B. RECOMMENDATIONS 

When accurate operational data is made available, thorough experi- 
mentation must be conducted to completely validate the model. These 
experiments should show that the model is an accurate representation 


of the system in every area which is to be studied by the use of this 


21 


simulation model. A jobstream should be chosen which depicts a wide 
variety of jobs representative of those presented to the computer 
facility for processing. Data must then be gathered from actually 
running this jobstream and comparisons made with the statistical out- 
put of the GPSS simulation of the same jobstream. Direct comparisons 
should then be made of all queue sizes, taks processing times, resource 
utilization, and Rial tasks processed. Care must be taken that jobs 
are run under the same configuration and parameter (number of initia- 
tors, readers, writers, etc.) circumstances and that observation inter- 
vals are the same for both system and model. 

Provided these experimental results show the model to be valid, it 
may be utilized in several capacities. Individual parameters should 
be varied to determine optimum operational methods. New modules may 
be added to test the efficiency of adding new equipment. Configuration 
may be varied to determine optimal equipment mixes. The jobstream can 
be modified to find better means of job classification. Measurements 
can be made at points in the model which are unavailable or difficult 
to obtain from the system. In any case, best results will be obtained 
if all sections except the one being studied are left unchanged at 
first. Secondary experimentation to study interaction effects should 


then be undertaken, 


C. CONCLUDING REMARKS 

To be effective the model must be simple. Only those portions of 
the simulation which are to be studied should be expanded in detail. 
A bulky model results in clouded results and becomes as time consuming 


as the system itself. 
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The results will be no better than the statistical information 
upon which it is based. Knowledge of the actual jobstream is there- 
fore of utmost importance, followed closely by machine timing infor- 
mation. With this data available for a base, sound predictions con- 


cerning new methods may be obtained. 
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CHAPTER V 


SUMMARY 


This paper reports on the design of a simulation model of the 
IBM 360 Computer operating in a Multi-programming with a Variable 
Number of Tasks (MVT) environment. The design is based on the 
operating system and computing equipment available at the U.S. Naval 
Postgraduate School's Computer Facility. 

The model is written in the General Purpose Simulation System/ 
360 (GPSS) language and is basically macroscopic in design. Each 
portion of the model can operate separately or be expanded in greater 
detail to allow for closer study of that particular aspect of opera- 
Elon: 

A brief outline of the System/360 is given; included is a 
description of the hardware components, responsibilities of the 
operating system, elements of the MVT environment, and further sys- 
tem references, 

There are seven major operational modules: a test jobstream 
generator; reader/interpreter; interruptor; and input/output. Also 
provided are an exponential function, commonly used variables, a 
clock, and a run control section. 

Since jobstream, timing, and overhead data were not available 
from the facility, the model was operatec using a pseudo jobstream 
for testing purposes. The results of the experiment were as antici- 
pated and showed the model to be viable. It was also found that the 
efficiency of the model was enhanced by reducing the number of trans- 


actions to a minimum and by simplifying operations to only a few of 
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the more important and/or time consuming steps. 

The full validation of the model requires the utilization of 
presently unavailable system and jobstream timing information; an 
outline of the required validation trials is included. Model utili- 
zation is described with the stipulation that the verifying simula- 
tion tests are favorable. 

It is concluded that simple models operate more efficiently 
and that many system and jobstream statistics must be known for 


effective model operation. 
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